[git-annex.git] /

[[!comment format=mdwn
 username="ewen"
 avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
 subject="Alternative proposal for better backwards compatibility"
 date="2023-07-12T12:48:03Z"
 content="""
Firstly, if `git annex assist` has been added to create the magical \"Dropbox like experience\", I don't see the need for changing the default behaviour of `git annex sync` at all.  (For the record I'm glad `git annex assist` exists; I don't need it, or want it, but it clearly solves a bunch of UI problems for some users, and that's great.  This is entirely about backwards incompatible UX changes in existing commands.)

Secondly, your (@nobodyinperson) suggestion for \"improving\" the current situation seems to be:

1.  Entirely remove `git annex sync` (entirely breaking backwards compatiblity) and/or have it permanently display a warning that cannot be removed (annoying, incompatible with anything looking at output); and
2.  Add a new (ie, not in any older version) `git annex metasync` which has some of the existing functionality, and some random other (unwanted by me at least) additional functionality (auto-adding any files in a directory where git annex is run, which I definitely do not want)

Which, to me, is *even more* breaking the user experience of using `git annex` for the last 8 years, than is currently happening.  AFAICT there would then be *no way* at all to get the `git annex` \"just sync metadata without other unwanted behaviour\" that existed before.  *And* it'd then require git annex version detection in scripts to tell if `git annex metadata --no-add-really-just-copy-metadata-honest` was available or not, or if one had to fall back to an old version of the command, which is a really user-hostile way to \"retain\" existing behaviour.  (FTR in my case at least there is *zero* chance that `git annex sync` would suddenly encounter `annex.synccontent=true`, as it's just me, and I haven't set that; I don't need a \"guarantees\" it won't copy content option, except as a defense against the git annex defaults suddenly changing after 8 years.)

My suggestion for preserving backwards compatibilty would be:

1.  Move the behaviour change out of `git annex sync` and into `git annex init` (rationale: it's run once per annex/machine pair, not many times per day/week, *and* it makes the change \"new annexes only\" which is much closer to \"opt in\")

2.  From git annex version N + 1, have git annex automatically set `annex.synccontent=true` at `git annex init` of a *new* repo (ie, not just naming the local copy of the annex), and for version N+1 to N+3 (or higher) have `git annex init` issue a warning it has defaulted sync content on now (unlike earlier versions), and describe how to find out how to turn it off (unless a global git setting is making `annex.synccontent=true` the user preferred default anyway, in which case the user doesn't need a warning of a setting matching their preferred option).

3.  For any annex where `annex.synccontent` is *not* set, assume it's an older annex, and use the backwards compatible, historical, default (false) *without* issuing any warnings about \"this is going to change\" (and never change that behaviour for historical annexes)

4.  Retain `git annex sync` forever, with it obeying `annex.synccontent` (default: false, but set to true in newly created annexes by default)

5.  Remove the newly added warning in `git annex sync` entirely, and just keep the functionality of the version before 10.20230623

This would:

1.  Allow changing the `git annex sync` default from `metadata only` to `full content` in a \"new usage, opt in only\" way

2.  Provide a clear path to opt out, and a clear path to opt in existing repos to match

3.  Avoid needing to issue warnings to users on every run of a very core command until they set config

4.  Avoid breaking existing usage, and use cases

The git annex \"meta data sync\" dance (which effectively allows `git push` into a repo that has a working directory attached, something that is normally otherwise difficult) was great, and the thing which made git annex attractive to me over other options.  It'd be a shame to render that great functionality unreachable without unwanted \"some users wanted this, so all users must have this\" functionality.

Ewen

PS: `git annex push` / `git annex pull` do not appear to be meta data only tools to replace sync; they appear to be very explicitly targetted at copying content, and to be one remote at at a time as well (where as sync is \"all known remotes\").  Historically it looks like my wrapper scripts use `git annex get ...` to retrieve content, and `git annex copy --to=REMOTE ...` to put content onto a specific remote (ie, a `put`, when there is no `put`).
"""]]